AD-A276  230 


U  1  iv> 

ELECTE 
MAR  1  1994 


NRL/FR/5520~94-9703 


A  Multichannel  Architecture  for  Naval 
Task  Force  Communication 


William  A.  Thoet 

Booz-Allen  &  Hamilton,  Inc. 
8283  Greensboro  Drive 
McLean,  VA  22102-3838 


Dennis  J.  Baker 
Dennis  N.  McGregor 

Communication  Systems  Branch 
Information  Technology  Division 


January  30, 1994 


bl"  2  28  065 


CTJ 


AT.' 


Approved  for  public  release;  distribution  unlimited. 


REPORT  DOCUMENTATION  PAGE 


Form  Approved 
OMBNo.  0704-0188 


PuWie  rtpflfting  buHton  f«r  thia  caiaction  al  intarmauan  ia  aatimatad  la  avaraoa  1  Kaw  par  raaponaa>  including  tha  lima  for  raviawing  maiructiana.  aaarefang  aaiaiing  data  aaureaa. 
gatfiaring  and  maimairawg  tha  data  naadod,  and  aamplatmg  and  raviawirig  tha  eattactian  af  tnfarmabarv.  Sartd  cammanta  regarding  thia  bwdart  aahmala  ar  arty  alhar  aapaet  of  thia 
caiactian  af  Marmadars  Including  auggaattana  far  reducing  thia  bvdan,  ta  WaaNngtan  Haadquartara  Sarvieaa.  Diractaraia  far  Infarmaban  Oparadana  and  Haparta.  1316  Jaffaraan 
Davia  Highway.  Sidta  1304.  Ardr^an.  VA  33303-4303.  wtf  la  tfw  Office  af  Maitagamani  «id  Sudgat.  Paparwarii  Raductian  Praiact  10704-01  Ml.  Waafar^an.  OC  30603. 


t .  AGENCY  USE  ONIY  Umv#  1 2.  REPORT  DATE 


3.  REPORT  TYPE  AND  OATES  COVERED 


January  30,  1994 


4.  THIE  AND  SUBTITLE 


A  Muhichannei  Architecture  for  Naval  Task  Force  Communication 


6.  AUTHORIS) 

William  A.  Thoct,*  Dennis  J.  Baker,  and  Dennis  N.  McGregor 


7.  PERFORMINa  ORQANIZATION  NAME(S)  AND  AOORESS(ES) 

Naval  Research  Laboratory 
Washington,  DC  20375-5320 


5.  FUNOmO  NUMBERS 

PE  -  63792N 
WU  -  DN 153-279 
PR  -  R1889 


8.  PERFORMING  ORGANIZATION 
REPORT  NUMBER 

NRUFR/5520-94-9703 


10.  SPONSORING/MONITORING 
AGENCY  REPORT  NUMBER 


1 2b.  DISTRIBUTION  CODE 


9.  SPONSORING/MONITORING  AGENCY  NAMEISI  AND  ADDRESSIESt 

Naval  Command,  Control  &  Ocean  Surveillance 
Center  RDT&E  Division 
San  Diego,  CA  92152-5122 


1 1 .  SUPPLEMENTARY  NOTES 

•Booz-AUen  &  Hamilton,  Inc.,  8283  Greensboro  Drive,  McLean,  VA  22102-3838 


12«.  OISTRIBUTION/AVAILABILITY  STATEMENT 

Approved  for  public  release;  distribution  unlimited. 


13.  ABSTRACT  {Maximum  200  words] 

This  report  describes  a  new  architecture  for  mobile,  narrowband,  broadcast  radio  networks,  which  is  called  the  Multichannel 
Architecture  (MCA).  We  compare  the  performance  limits  of  an  MCA  network  to  a  single-channel  architecture  based  on  an  Ideal 
Handoff  Assigned  Multiple  Access  (IHAMA)  protocol.  Both  architectures  have  been  proposed  for  Naval  inlralask  force 
communications  with  HF  and  line-of-sight  UHF  radio.  Formulas  for  the  network  load  capacity  for  each  architecture  arc  derived  for 
several  important  cases,  and  simulation  results  are  presented  for  those  cases  where  analytical  results  are  not  available.  Based  on 
“equivalent”  equipment,  the  load  capacity  of  MCA  is  shown  to  exceed  that  of  IHAMA.  MCA  also  out-performed  IHAMA  in  other 
performance  areas  such  as  delay,  the  ability  to  handle  voice  and  virtual  circuits,  and  jam  resistance. 


14.  SUBJECT  TERMS 

Networking 

Mobile  networks 

H.F. 

High  frequency  communication 

17.  SECURITY  CLASSIFICATION 

18.  SECURITY  CLASSIFICATION 

19.  SECURITY  CLASSIFICATION 

OF  REPORT 

OF  THIS  PAGE 

OF  ABSTRACT 

UNCLASSIHED 

UNCLASSIRED 

UNCLASSIRED 

NSN  7540-01-280.5500 


15.  NUMBER  OF  PAGES 
33 


16.  PRICE  CODE 


20.  LIMITATION  OF  ABSTRACT 


Slandird  Form  268  (Rqv.  2-89) 
PrMcribwf  by  ANSI  Std  239-18 
298-102 


CONTENTS 


1.  INTRODUCTION  . 1 

1.1  Operational  Environment . i 

1.2  Conc^t  of  Operation . 2 

1.3  Definitions . 3 

2.  ALTERNATIVE  ARCHITECTURES  FOR  INTRATASK  FORCE  NETWORKS . 4 

2.1  A  Fixed  Time  Division  Multiple  Access  Approach . 4 

2.2  Ideal  Handoff  Assigned  Multiple  Access  Approach . 5 

2.3  HF  nr  Network  Approach  . 7 

2.4  Multichannel  Architecture  (MCA)  . 7 

3.  NETWORK  PERFORMANCE  RESULTS  . 11 

3.1  Random  Network  Generation  .  11 

3.2  Load  Capacity .  11 

3.3  Equipment  Normalized  Results . 13 

3.4  Related  Issues . 13 

4.  CONCLUSIONS  . 20 

REFERENCES  . 21 

APPENDIX  —  Approximating  the  Minimum  Backbone  Network . 23 


Accesion  For 


NTIS  CRA&I 
DTIC  TAB 

U!idnnoii”ced 


6y _ _ 

Dislribution  / 


? 


□ 

a 


Avdildbility  Codes 


Oisl 


Avail  and  I  or 
Special 


A  MULTICHANNEL  ARCHITECTURE  FOR  NAVAL  TASK  FORCE 

COMMUNICATION 


1.  INTRODUCTION 

The  present  Naval  intratask  force  communication  system  was  deployed  in  1959.  Modem  advances  in 
weapons  and  sensor  technology,  and  the  advent  of  digital  Command,  Control,  Communications,  Comput¬ 
ers,  and  Intelligence  (C'^I)  systems  have  increased  communication  system  requirements,  resulting  in  recent 
efforts  to  improve  or  replace  the  existing  Link- 11  architechire.  In  addition  to  meeting  the  requirements 
imposed  by  the  modernization  of  weapons  systems,  the  replacement  systems  must  face  a  more  technologi¬ 
cally  advanced  adversary.  Modem  communication  jamming  systems  are  a  major  threat  to  an  intratask  force 
communication  system's  integrity.  To  be  able  to  capitalize  on  the  advanced  weapons  systems  and  C^I  sys¬ 
tems,  the  communication  system  must  also  be  able  to  respond  to  jamming  effectively. 

As  in  the  case  of  Link-1 1,  it  can  be  expected  that  any  communication  system  installed  in  the  late  1990s 
will  still  be  in  use  through  the  first  quarter  of  the  21st  century.  Over  this  time  period,  communications 
requirements  are  likely  to  increase  dramatically.  Thus,  the  communication  architecture  should  be  designed 
for  modular  expansion  to  fit  these  future  needs  in  a  cost-effective  fashion. 

In  this  report,  we  describe  one  such  system,  the  Multichannel  Architecture  (MCA)  and  compare  its 
performance  with  the  dominant  single-chaimel  approach,  Handoff  Assigned  Multiple  Access  (HAMA).  We 
show  that  the  MCA  is  able  to  handle  much  larger  loads  and  with  much  lower  delays  than  comparably 
equipped  HAMA  systems.  In  addition,  the  ability  to  generalize  the  MCA  to  use  arbitrary  numbers  of 
receivers  provides  a  cost-effective  path  to  system  expansion. 

The  report  is  organized  as  follows.  We  complete  Section  1  by  examining  the  operational  environment, 
describing  the  model  of  our  concept  of  operation  for  an  intratask  force  network,  and  providing  definitions 
of  the  symbols  and  terms  that  we  use.  Section  2  describes  three  architectures  that  have  been  proposed  for 
intratask  force  communications  with  high  flrequency  (HF)  and  line-of-sight  ultrahigh  frequency  (UHF) 
radio,  namely,  a  single-channel  architecture  based  on  an  Ideal  HAMA  (IHAMA)  protocol,  a  multichannel 
architecture  called  the  HF  Intratask  Force  (ITF)  Network,  and  a  successor  to  the  latter  called  the  Multi¬ 
channel  Architecture.  Formulas  are  derived  for  computing  the  network  load  capacity  for  IHAMA  and 
MCA  architectures  for  several  important  cases.  Section  3  shows  the  results  of  the  comparisons  in  chart 
form.  Section  4  presents  our  conclusions. 

1.1  Operational  Environment 

Before  describing  Ideal  HAMA  and  MCA,  it  is  important  to  characterize  the  intratask  force  communi¬ 
cation  environment.  The  environment  is  defined  by  several  factors;  topology,  communications  medium, 
and  classes  of  service.  All  of  these  are  important  factors  for  consideration  in  the  design  of  an  intratask 
force  network. 


Manuscript  approved  July  30,  1993. 


1 


2 


Thoet,  Baker,  and  McGregor 


One  of  the  more  demanding  aspects  of  designing  an  intratask  force  network  architecture  results  from 
die  continual  relative  motion  of  the  communication  platforms.  This  movement  requires  the  system  to 
adjust  to  changing  communication  topologies.  The  varying  channel  characteristics  of  HF  and  UHF  com¬ 
munication  can  cause  further  topological  change.  These  topological  changes  are  intensified  during  an 
actual  conflict  Under  battle  conditions,  systems  can  experience  equipment  failure,  node  attrition,  and  jam¬ 
ming.  To  adjust  to  all  of  these  factors,  a  communication  system  must  be  able  to  reorganize  its  assets 
quickly  and  use  its  new  structure  effectively.  Thus,  the  reorganization  technique  must  be  rapid,  robust,  and 
efficient. 

The  choice  of  communication  media  is  also  an  important  factor  in  determining  an  effective  network¬ 
ing  strategy.  For  a  variety  of  technical  and  operational  reasons,  HF  and  UHF  broadcast  links  are  used  for 
intratask  force  communication.  HF  has  the  advantage  of  extended  line  of  sight  (FLOS)  transmission  at 
data  rates  on  the  order  of  2400  bps.  However,  the  range  decreases  with  increasing  frequency.  UHF  offers 
higher  data  rates  (9600  bps),  but  is  limited  to  line  of  sight  (LOS)  propagation.  Due  to  the  limitations  of 
Link-11,  current  intratask  force  systems  use  the  low  end  of  the  HF  band  to  increase  the  likelihood  of  full 
connectivity.  The  structure  of  modem  naval  task  forces  and  the  limited  range  of  10  to  30  MHz  HF  and  of 
UHF  transmissions  require  message  relaying  when  full  connectivity  is  not  provided.  Relaying  is  not  cur¬ 
rently  implemented  in  Link-11.  By  using  modem  networking  concepts,  the  10  to  30  MHz  HF  and  UHF 
bands  can  be  “opened  up”  for  use  in  intratask  force  communication. 

Every  communication  system  is  designed  to  support  an  application  or  set  of  applications.  The  commu¬ 
nication  needs  of  these  applications,  coupled  with  the  topological  factors  described  above,  form  the  speci¬ 
fication  of  the  network.  The  requirements  that  intratask  force  applications  impose  upon  the  communication 
system  can  be  broken  down  into  several  “classes  of  service.”  A  class  of  service  can  be  defined  as  a  set  of 
message  delivery  requirements  imposed  on  a  communication  system  by  an  application.  Message  types  that 
differ  significantly  in  timeliness,  throughput,  or  reliability  requirements  need  different  protocols  for  deliv¬ 
ery.  In  addition,  different  resources  may  need  to  be  applied  to  achieve  the  class  of  service. 

The  traffic  used  in  modern  intratask  force  systems  can  be  broken  down  into  three  general  classes  of 
service:  target  reports  (Naval  Tactical  Data  System  (NTDS)  data),  computer-to-computer  data,  and  voice. 
Each  of  these  classes  makes  quite  different  requirements  of  the  system.  NTDS  traffic  has  high-volume, 
low-delay  requirements.  In  fact,  if  data  is  old,  it  can  simply  be  replaced  by  more  up-to-date  data.  Com- 
puter-to-computer  data  has  greatly  varying  requirements.  Downloading  data,  downloading  code,  and  com¬ 
munication  for  distributed  C^I  systems  are  all  potential  uses  of  this  class  of  service.  One  factor  that  is 
shared  by  computer-to-computer  communication  is  the  need  for  high  reliability.  The  last  class  of  service 
and  perhaps  the  most  difficult  to  implement  is  voice.  Voice  requires  high  bandwidth  (1200  to  9600  bps), 
low  delay  (-1  s),  and  ordered  delivery.  Since  HF  channels  are  typically  able  to  sustain  only  about  2400 
bps,  voice  delivery  requirements  are  very  stressing  for  HF  networks. 

Quantitative  conununication  requirements  of  future  Naval  intratask  force  networks  are  still  not  clear. 
But  the  need  to  implement  the  three  classes  of  service  mentioned  and  provide  a  path  to  future  expansion  to 
higher  throughputs  and  lower  delay  is  clear.  Therefore,  a  network  architecture  that  can  implement  the  three 
classes  of  service  and  be  easily  and  economically  updated  is  needed.  We  believe  that  the  Multichannel 
Architecture,  which  is  described  in  this  report,  can  fulfill  this  need. 

1.2  Concept  of  Operation 

To  provide  a  basis  for  comparing  alternative  network  architectiu’es,  we  assume  a  simple  communica¬ 
tion  mode!  with  a  given  communication  range.  This  results  in  a  network  in  which  all  connectivities  are 
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bidirectional.  Within  this  communication  environment,  each  of  the  networks  that  we  are  examining  share 
the  same  concept  of  operation,  which  we  describe  in  this  section. 

The  traffic  model  that  we  have  chosen  as  our  basis  of  comparison  is  one  in  which  data  traffic  is  uni¬ 
formly  generated  by  each  of  the  network  nodes,  and  this  traffic  is  broadcast  to  all  other  nodes  in  the  net¬ 
work.  The  mechanism  for  implementing  this  broadcast  service  is  to  organize  a  subset  of  the  network  nodes 
into  a  set  of  relays  called  the  Backbone  Network  (BN).  (In  the  Ap^ndix,  we  discuss  several  techniques  for 
establishing  a  backbone  network.)  Any  valid  set  of  relays  must  fulfill  two  criteria:  1)  every  node  in  the  net¬ 
work  must  be  connected  to  at  least  one  relay  and  2)  the  relays  must  form  a  connected  subnet V  In  many 
cases,  by  minimizing  the  number  of  required  relay  nodes  used  for  a  network,  the  performance  of  the  net¬ 
work  can  be  optimized.  A  valid  set  of  relays  with  the  minimum  number  of  relays  is  termed  a  Minimum 
Backbone  Network  (MBN). 

Each  relay  is  responsible  for  servicing  the  traffic  entry  for  all  of  the  neighboring  nonrelay  nodes  and 
forwarding  all  other  messages.  In  some  cases,  not  all  traffic  must  be  relayed.  We  assume  that  sufficient 
information  is  available  at  a  node  that  is  receiving  a  transmission  to  ascertain  whether  the  transmitting 
node  is  directly  connected  to  all  other  nodes  in  the  network.^  When  this  is  the  case,  the  transmitting  node  is 
said  to  be  “fully  connected.”  Thus,  if  the  transmitting  node  is  fully  connected,  its  transmissions  are  not 
relayed.  If  all  nodes  in  the  network  are  fully  connected,  the  network  is  said  to  be  fully  connected.  If  one  or 
several  (but  not  all)  nodes  are  connected  to  all  other  nodes  in  the  network,  the  network  is  said  to  be  “star 
connected.”  If  none  of  the  nodes  are  fully  connected,  we  call  the  network  a  “multihop  network.”  In  a  mul¬ 
tihop  network,  all  traffic  needs  to  be  relayed.  In  our  model,  we  assume  that  traffic  that  is  relayed  is  trans¬ 
mitted  by  all  relay  nodes. 

Once  a  backbone  network  is  defined,  transmission  capacity  is  then  allocated  to  each  node  in  the  net¬ 
work.  This  capacity  is  allocated  in  such  a  way  that  all  relay  nodes  are  given  extra  transmission  capacity  to 
handle  relay  traffic  in  addition  to  the  traffic  that  they  are  generating  (i.e.,  new  traffic).  Based  on  this  opera¬ 
tional  model,  we  determine  the  limit  of  the  traffic  the  network  can  generate  (i.e.,  the  load  capacity  of  the 
network). 

1.3  Definitions 

We  define  the  following  symbols. 

B  Number  of  relay  nodes  in  the  backbone  network. 

C  Maximum  information  rate  obtainable  from  a  single  transmitter. 

The  part  of  a  transmitter’s  capacity  that  is  used  for  relay  traffic. 

D  Network  dispersion;  In  our  simulation  model  of  networks,  nodes  are  randomly  positioned 

within  a  square  whose  sides  are  of  length  D. 

F  Number  of  frequencies  available  for  use  by  MCA. 

F,  j  Probability  that  node  j  has  a  receiver  tuned  to  node  i. 


1.  Assuming,  of  course,  that  the  original  network  is  connected. 

2.  An  example  of  a  protocol  for  learning  local  connectivities  in  a  broadcast  radio  network  is  given  in  Ref.  1. 
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Maximum  value  of  Xj  for  the  entire  network. 

k  Number  of  fully  connected  nodes. 

L  Load:  The  load  on  the  entire  network;  L  =  Nl 

^max  capacity:  The  maximum  load  that  can  be  sustained  by  the  network: 

^  max  Normalized  load  cs^acity:  »  ^max'^^*  where  “a*’  means  “is  defined  as.” 

L"  Equipment-normalized  load  capacity  (ENLC);  This  is  defined  as  divided  by  the 

number  of  transmit  and  receive  strings  per  node.  For  example,  if  there  are  one  transmitter 
and  one  receiver  per  node,  then  the  divisor  is  2.  On  the  other  hand,  if  there  are  one  trans¬ 
mitter  and  five  receivers  per  node,  the  divisor  is  6. 

/  Load  per  node:  This  is  the  amount  of  new  traffic  that  is  generated  by  each  node,  lb  sim- 

I^fy  the  task  of  comparing  alternative  network  architectures,  we  assume  a  uniform  load 
per  node. 

^max  capacity  per  node:  This  is  the  maximum  amount  of  new  traffic  that  can  be  generated 

by  each  node. 

N  Number  of  nodes  in  the  network. 

rij.  Number  of  receivers  per  node. 

Pj  Percentage  of  traffic  sourced  by  node  j. 

Tp  Packet  transmission  duration. 

Xj  Number  of  relay  nodes  connected  to  node  j. 

p  Communication  Range. 

p'  Normalized  Communication  Range:  p' s  p/D.  See  Fig.  1  and  the  accompanying  c:q)tion. 

2.  ALTERNATIVE  ARCHITECTURES  FOR  INTRATASK  FORCE  NETWORKS 
2.1  A  Fixed  Time  Division  Multiple  Access  Approach 


A  simple  approach  to  handling  relaying  in  networks  is  to  operate  on  a  single-frequency.  Fixed  Time  Di¬ 
vision  Multiple  Access  (FTDMA)  schedule.  In  a  FTDMA  system,  each  node  in  the  network  is  assigned  a 
time  slot  in  a  schedule  in  which  it  can  transmit  These  time  slots  are  assigned  so  that  no  two  transmitters 
operate  at  the  same  time.  By  scheduling  in  this  fashion,  there  is  no  chance  of  a  transmission  scheduling  con¬ 
flict  i.e.,  two  transmitters  scheduled  at  the  same  time  at  the  same  frequency.  However,  the  FTDMA  is  inef¬ 
ficient  for  systems  with  uneven  traffic  creation  rates  or  relaying.  For  a  multihop  network  that  uses  FTDMA, 
the  entire  traffic  load  must  pass  through  each  relay  node.  Since  the  maximum  allowed  transmission  rate  per 
node  in  an  FTDMA  network  is  C/N  (irrespective  of  whether  or  not  a  node  is  a  relay),  the  maximum  load 
(i.e.,  load  capacity)  that  the  network  can  sustain  is  given  by 
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Fig.  1  —  Definition  of  die  Nonnalized  Communication 
Range  p' .  In  our  simulation  model,  nodes  are  positioned 
randomly  in  a  square  region  of  width  D .  All  nodes  within 
communication  range  p  are  connected  to  each  other.  The 
Normalized  Communication  Range  is  defined  as  the  ratio 
p'  =  p/D. 


^maz  ”  (multihop  FTDMA  network) 

or,  in  terms  of  the  normalized  load  capacity, 

L'max  =  1/iV  (multihop  FTDMA  network). 

Therefore  the  load  capacity  varies  inversely  with  the  network  size. 

2.2  Ideal  HandofT  Assigned  Multiple  Access  Approach 

A  modification  of  FTDMA  can  be  made  to  allow  unequal  amounts  of  transmission  time  at  each  node. 
However,  if  the  system  is  dynamic,  a  protocol  must  be  established  that  allocates  capacity  to  nodes  accord¬ 
ing  to  their  requirements.  One  method  of  doing  this  in  a  distributed  way  is  to  have  nodes  “hand  off’  a  por¬ 
tion  of  their  edacity  to  a  neighbor.  This  technique  is  known  as  Handoff  Assigned  Multiple  Access 
(HAMA)  [2,  3].  After  capacity  handoff  is  complete,  the  system  operates  in  a  fashion  similar  to  FTDMA, 
except  that  some  nodes  get  more  slots  than  oth^. 

Figure  2  shows  a  sequence  of  slot  reallocations  that  occur  in  an  Ideal  HAMA  (IHAMA)  system  for  a 
simple  network.  The  example  eight-node  network  requires  that  three  nodes  (solid-filled  circles)  act  as  relay 
nodes.  Initially  (panel  (a)),  each  node  is  allocated  100  minislots  per  firame.^The  example  assumes  that  each 
node  computes  the  ideal  capacity  allocation,  shown  in  panel  (c).  For  the  example  topology,  the  ideal  cq)ac- 
ity  allocation  is  achieved  in  two  steps.  In  the  first  step  (panel  (b)),  nonrelay  nodes  forward  unneeded  capac¬ 
ity  to  neighboring  relay  nodes.  In  the  second  step  (panel  (c)),  capacity  is  distributed  uniformly  to  all  relay 
nodes. 

When  examining  the  optimal  behavior  of  an  IHAMA  system,  one  can  assume  the  capability  for  per¬ 
manent  slot  handoff  and  very  many  slots  per  node  per  firame.  This  IHAMA  gives  an  upper  bound  to  the 
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Fig.  2  —  Relayed  allocatioo  in  an  ideal  HAMA  system,  a)  Network  before  capacity 
assigmneat  has  100  minislots  per  node,  b)  Nonreiay  nodes  forward  all  unneeded  capac¬ 
ity  to  neighboring  nodes,  c)  Firud  capacity  allocation  takes  {dace. 


performance  of  a  real  HAMA  system.  To  see  what  kind  of  througlput  an  iV-node,  IHAMA  system  can 
achieve,  we  can  divide  the  system  transmission  capacity  into  relay  capacity  and  new  traffic  generation 
capacity.  For  this  analysis,  all  platforms  are  assumed  to  generate  new  traffic  at  the  same  rate  1 .  (The  results 
are  only  slightly  affected  by  a  nonuniform  traffic  generation.)  For  broadcast  traffic  and  a  multihop  network, 
we  can  assume  that  each  of  the  B  relay  nodes  needs  to  relay  all  of  the  traffic  except  the  traffic  it  creates; 

=  {N-  1)/.  Ihus,  the  total  transmission  capacity  used  by  the  system  is  B{N-  l)l  +  Nl.  In  the 
IHAMA  system,  all  transmitters  share  access  to  a  single,  common  channel.  Therefore,  the  system  capacity 
is  equivalent  to  the  transmission  capacity  C  of  a  single  node  that  is  allowed  to  transmit  all  of  the  time. 
Thus,  the  load  edacity  per  node  for  an  IHAMA  network  can  be  obtained  from  the  equation 
B(N-l)  =  C,  and  the  load  capacity  of  the  entire  network  is 

^max  ~  ^^max  =  C/  (fi  +  1  -  B/N)  «  C/  (B  +  1 )  (multihop  IHAMA  network). 

The  equations  become  more  complex  if  the  nodes  have  differing  traffic  generation  capacities.  In  either 
case,  the  more  relay  nodes  used,  the  lower  the  load  cjq>acity  of  the  system.  Thus,  the  load  capacity  varies, 
approximately,  with  the  number  of  relay  nodes  required. 

The  situation  is  a  little  different  for  star-connected  IHAMA  networks.  We  let  k  denote  the  number  of 
fully  connected  nodes  in  the  network.  The  transmission  capacity  is  divided  into  relay  traffic  iN-k)l  and 
nonrelay  traffic  Nl.  Equating  this  traffic  level  to  the  total  transmission  cj^acity  C  of  the  system,  we  can 
solve  for  the  load  capacity  per  node.  This  leads  us  to  the  following  expression  for  the  normalized  load 
capacity. 


^'max=  l/(2-k/A0 


(IHAMA  network  with  k  fully  connected  nodes). 


Here,  l^k^N.  Thus,  for  an  IHAMA  network  with  only  one  node  that  is  fully  connected. 


^'max“l/2. 
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For  fully  connected  IHAMA  networks,  no  relaying  is  necessary.  In  that  case,  the  load  capacity  is  lim¬ 
ited  by  the  need  for  all  nodes  to  share  a  single  channel  of  capacity  C.  Therefore,  for  this  case  we  have 

^  max  "  ^  (fully  connected  IHAMA  network). 

2.3  HFITF  Network  Approach 

Another  intratask  force  networking  concept  is  the  HF ITF  Network  [4,  5].  This  network  is  developed 
around  a  network  structure  known  as  the  Linked  Ouster  Architecture  (LCA)[1,  6],  The  HF  ITF  Network 
uses  a  distributed  protocol  called  the  Linked  Cluster  Algorithm  to  set  up  and  maintain  the  Linked  Cluster 
structure.  Figure  3  shows  the  nomenclature  for  describing  the  LCA.  Nodes  are  assigned  one  of  the  follow¬ 
ing  labels  in  this  architecture;  clusterhead,  gateway,  or  ordinary.  For  simplicity,  the  example  is  for  the  case 
of  a  fixed  communication  range  model  —  the  communication  range  of  each  clusterhead  is  shown  by  the 
radius  of  the  surrounding  circle.  With  this  simple  model,  clusters  can  be  easily  identified.  A  cluster  consists 
of  a  set  of  nodes  that  are  bidirectionally  linked  to  a  common  clusterhead  node.  A  node  can  be  connected  to 
several  clusterheads,  depending  on  the  topology.  However,  because  of  the  way  clusterheads  are  selected, 
they  are  never  directly  connected.  This  tends  to  spread  out  the  clusters.  An  isolated  clusterhead  is  a  cluster 
with  only  one  member,  i.e.,  itself.  Every  node  is  either  a  clusterhead  or  is  bidirectionally  connected  to  a 
clusterhead.  An  adjacent  pair  of  clusterheads  can  be  linked  either  by  a  single  relay  (adjacent,  overlapping 
clusters)  or  by  two  relay  nodes  (adjacent,  non-overlapping  cases).  Figure  3  shows  both  cases.  If  several 
nodes  can  act  as  relays  to  link  adjacent  clusterheads,  the  Linked  Cluster  Algorithm  designates  a  preferred 
relay  (adjacent  overlapping  clusters)  or  relay  pair  (adjacent  non-overlapping  clusters).  Such  a  node  is 
called  a  gateway.  Nodes  that  are  neither  clusterheads  nor  gateway  nodes  are  referred  to  as  ordinary  nodes. 

In  the  HF  ITF  Network,  the  LCA  is  used  to  facilitate  the  routing  of  traffic  and  to  allocate  channel 
capacity.  The  HF  ITF  Network  is  a  multichannel  network,  which  can  be  implemented  with  either  narrow- 
band  or  spread  spectrum  channels.  For  the  case  of  narrowband  channels,  which  is  the  focus  of  this  report, 
each  node  is  assigned  a  unique  transmit  frequency.  This  allows  several  nodes  to  transmit  simultaneously 
without  interfering.  However,  to  take  advantage  of  multiple,  simultaneous  hansmissions,  several  receivers 
(approximately  five)  are  needed  for  each  platform.  The  transmission  slot  allocations  are  determined  by  the 
clusterheads.  Each  clusterhead  produces  a  Cluster  Transmission  Schedule  for  those  nodes  within  its  clus¬ 
ter.  The  result  is  a  transmission  schedule  for  every  cluster  plus  an  additional  FTDMA  schedule,  which 
operates  in  parallel  with  the  Cluster  Transmission  Schedules  [4], 

As  networks  become  sparse  (dispersed  relative  to  the  communication  range)  the  number  of  relays 
grows,  reducing  IHAMA  performance.  However,  since  spars  j  networks  result  in  more  clusters  in  the  LCA, 
the  extra  transmission  capacity  of  the  additional  Cluster  Transmission  Schedules  tends  to  compensate  for 
the  increased  number  of  relays.  This  is  in  contrast  to  IHAMA  whose  load  capacity  decreases  with  an 
increasing  number  of  relays  and  FTDMA  whose  load  capacity  decreases  with  an  increasing  number  of 
nodes.  The  HF  ITF  Network  requires  several  (approximately  five)  receivers  per  node  to  accomplish  this. 
However,  if  high  load  capacity  is  required,  the  HF  ITF  Network  provides  this  capacity  more  cheaply  than 
do  IHAMA  architectures  since  it  is  achieved  with  added  receivers,  not  added  transmitter-receiver  pairs. 

2.4  Multichannel  Architecture  (MCA) 

The  MCA  is  a  logical  development  from  the  concepts  first  introduced  with  the  LCA  and  later  brought 
to  fruition  in  the  HF  ITF  Network.  Like  the  HF  ITF  Network,  it  uses  multiple  frequencies  and  periodic 
structural  reorganization  to  enhance  its  load  capacity  and  reliability.  However,  several  significant  changes 
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0  Clusterhead 
0  Gateway  Node 


Fig.  3  —  The  Linked  Cluster  Architecture 

in  the  methodology  used  tor  transmitter  and  receiver  scheduling  as  well  as  tlte  generalization  ot  LCA  for 
arbitrary  transmission,  reception,  and  frequency  resources  warrant  a  different  name  for  the  architecture. 

The  HF  ITF  Network’s  transmission  capacity  is  limited  by  the  number  of  clusters,  and  each  node 
requires  several  receivers.  Further  studies  of  the  HF  ITF  Network  [7,8]  led  to  the  development  of  a  new 
network  architecture  called  the  Multichannel  Architecture.  Key  differences  between  the  HF  ITF  Network 
and  the  MCA  are  that  the  latter  allows  any  transmitter  to  transmit  at  any  time  and  allows  arbitrary  numbers 
of  transmitters  and  receivers  per  platform^. 

Many  of  the  differences  between  the  HF  ITF  Network  and  MCA  are  the  re.sult  of  the  particular  a[^li- 
cations  for  which  they  were  initially  designed.  Originally,  the  HF  ITF  Network  was  designed  for  use  in  a 
Frequency-Hopping  (FH)  spread  spectrum  system.  In  this  system,  each  transmitter  was  assigned  a  unique 
FH  code.  However,  two  or  more  transmissions  could  interfere  with  each  other.  For  that  reason,  forward 
error  correction  techniques  (FEC)  were  needed.  However,  for  the  spread  spectrum  application,  FEC  only 
works  if  the  cochannel  interference  levels  are  small  enough.  Studies  showed  that  the  number  of  interfering 

3.  The  limiting  case  of  the  number  of  transmitters  on  a  platform  is  likely  to  be  governed  by  the  tolerable  level  of  co¬ 
channel  interference  at  the  collocated  receivers. 
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transmissions  should  be  held  to  five  or  less.  This  constraint  led  to  the  decision  to  limit  the  number  of  simul¬ 
taneous  transmissions  in  the  HF  ITF  Network  to  one  per  cluster  plus  the  FTDMA  transmission.  When  it 
became  apparent  that  the  required  HF  spread  spectrum  hardware  would  not  be  available  in  the  near  future, 
interest  turned  to  the  application  of  the  HF  ITF  Network  protocols  to  narrowband  systems.  The  concept 
was  to  use  multiple,  nanowband  frequency  channels  in  place  of  the  FH  channels.  No  modifications  of  the 
HF  ITF  Network  protocols  were  needed  to  adapt  them  to  this  “new”  application.  On  the  other  hand,  from 
tiie  start  the  MCA  was  designed  as  a  narrowband  system  in  which  the  signalling  chaiuiels  are  essentially 
orthogonal  (i.e.,  noninterfering).  Under  these  assumptions,  it  is  no  longer  necessary  to  limit  the  number  of 
simultaneous  transmissions,  as  was  done  in  the  HF  ITF  Network.  Of  course,  allowing  fiansmitters  to  trans¬ 
mit  at  any  time  precludes  the  use  of  the  MCA  for  spread  spectrum  systems  where  cochannel  interference  is 
a  limiting  factor. 

2. 4. 1  Network  Reorganization 

Like  the  HF  ITF  Network,  the  MCA  organizes  the  network  into  clusters  and  obtains  an  intermediate 
BN  using  the  Linked  Cluster  Algorithm.  Additional  uansmission  frames,  beyond  the  two  required  by  the 
Linked  Cluster  Algorithm,  are  then  used  by  the  MCA  to  obtain  the  final  BN,  which  better  approximates  an 
MBN.  These  two  steps  arc  contained  in  pseudocode  appearing  in  the  Appendix.  It  is  this  final  BN  that  per¬ 
forms  all  of  the  routing  in  the  MCA  system.  An  important  difference  in  the-lvlCA  is  the  absence  of  a  dedi¬ 
cated  FTDMA  schedule  (and  receiver)  for  handling  the  control  messages  for  reorganization.  Instead,  the 
reorganization  messages  can  periodically  use  slots  in  the  variable  schedules  for  sending  these  control  mes¬ 
sages. 

2.4.2  Transmitter  and  Receiver  Scheduling 

A  significant  difference  between  the  HF  ITF  Network  and  MCA  is  the  way  in  which  transmissions  are 
scheduled.  The  HF  ITF  Network  uses  cluster  schedules  in  which  each  clusterhead  hands  out  a  portion  (or 
all)  of  its  cluster  schedule  capacity  to  neigiiboring  nodes.  Each  nonclusterhead  node  then  announces  its 
transmission  schedule.  This  allows  the  receivers  of  neighboring  nodes  to  schedule  appropriately.  Thus,  the 
scheduling  is  transmission  driven. 

The  MCA  takes  advantage  of  the  fact  that  in  a  narrowband,  multichannel  system,  the  factor  that  limits 
transmissions  is  the  receiver’s  ability  to  listen.  Therefore,  in  the  MCA,  after  the  relays  are  determined, 
each  relay  computes  its  receiver  schedule(s)  and  announces  them.  Each  node  schedules  its  receivers  to 
give  equal  time  to  each  neighboring  node  on  the  backbone  and  some  time  to  listen  to  neighboring  ordinary 
nodes.  The  receiver  schedules  are  used  to  decide  which  message  is  to  be  transmitted  at  each  transmission 
opportunity.  If  the  number  of  neighbors  exceeds  the  number  of  receivers,  multiple  transmissions  of  the 
same  message  may  be  necessary.  This  is  in  marked  contrast  with  both  the  HF  ITF  Network  and  IHAMA  in 
which  all  neighboring  nodes  always  listen  to  the  transmission.  However,  because  any  node  can  transmit  all 
of  the  tiiTt  in  the  MCA,  the  extra  transmissions  do  not  adversely  affect  throughput  performance. 

2.4.3  Estimating  Load  Capacity 

Fully  connected  networks  in  IHAMA  and  MCA  require  no  relaying.  For  MCA,  this  leads  to  the  pleas¬ 
ant  result  that 


^  max  “  (fully  connected  MCA  network). 
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A  star  network  is  not  fully  connected,  but  it  does  contain  one  or  more  nodes  connected  to  all  others  in 
the  network.  These  k  fully  connected  nodes  can  be  used  as  relays. With  receivers  per  node,  two  cases 
must  be  considered,  and  k  <  n^.  For  the  former  case,  the  first  fully  connected  nodes  can  be  used 
as  relays.  The  total  relay  traffic  needs  of  the  remaining  (N-n^)  nodes  can  be  equally  divided  among 
these  relay  nodes.  Thus,  each  relay  node  needs  to  transmit  data  at  the  rate  ( (A  -  (//«^)  +  /)  ■  Equat¬ 

ing  this  transmission  rate  to  C,  we  can  solve  for  the  normalized  load  capacity  to  obtain 

^  max  ~  MCA  network  with  <  k). 

If  it  <  n^,  then  the  relay  traffic  can  be  divided  among  k  relays.  In  that  case,  each  relay  node  needs  to 
transmit  data  at  the  rate  {(N-k)  {l/k)  +  /) .  Equating  this  rate  to  C,  we  can  obtain  the  normalized  load 
capacity 


^'max  ~  *  (star  MCA  network  with  A:  <  n^). 

It  is  straightforward  to  show  that  the  load  capacity  of  an  MCA  mulithop  network  for  the  case  where 
the  number  of  receivers  per  node  always  exceeds  the  number  of  relay  nodes  to  which  any  node  is 
directly  connected  is  given  by 


^'max  “  ^  (multihop  MCA  network  with 

For  situations  in  which  the  number  of  receivers  is  the  determination  of  the  load  capacity  is 

much  more  complex.  The  rate  at  which  relay  node  i  can  empty  its  input  buffers  is  dependent  on  how  many 
relay  neighbors  node  i  has  (X,.),  the  probability  that  neighboring  relay  j  has  a  receiver  tuned  to  node  i 
(F,-  j),  and  the  percentage  of  the  total  system  load  received  from  nonrelay  nodes  by  node;  (Pp.  j  is 
equal  to  mind,  n/  {Xj  +  Pj) )  since  node ;’s  receivers  must  divide  their  time  between  listening  to  adjacent 
relay  nodes  and  to  the  nonrelay  nodes  that  it  must  service.  If  each  node  is  generating  the  same  traffic  load, 
then  the  percentage  of  traffic  generated  by  each  node  is  simply  \/N.  We  assume  that  a  nonrelay  node  dis¬ 
tributes  this  traffic  uniformly  over  the  relay  nodes  to  which  it  is  connected.  As  a  result,  Pj  is  obtained  from 
the  equation 


f 


where  the  sum  is  performed  over  all  nonrelay  neighbors  of  node  ;. 


To  evaluate  the  average  performance  of  a  relay  node  under  the  MCA,  a  queueing  simulation  was  con¬ 
structed  to  evaluate  the  number  of  slots  needed  to  empty  a  queue  of  10,000  messages  as  a  function  of  X-, 
F  •,  and  P-,  where  F  ■  =  min{F-  j).  The  reciprocal  of  the  number  of  transmission  periods  needed  for  each 
message  was  used  as  the  performance  of  the  relay  node.  These  results  were  computed  for  1  <  X-  <  6 , 
0  <  Fj.  <  1 ,  and  0  <  F,-  <  1 ,  resulting  in  a  table  of  performance  results.  These  tables  were  used  to  look  up 
the  performance  of  each  relay  node  in  the  simulations. 


After  all  of  the  relay  node  performance  estimates  were  computed,  the  minimum  performance  was  used 
to  measure  the  throughput  performance  of  the  system.  This  follows  from  the  fact  that  we  were  modelling  a 
system  using  only  broadcast  traffic;  therefore,  all  traffic  used  every  relay.  Thus,  the  minimum  capacity 
relay  limited  the  system  throughput. 
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3.  NETWORK  PERFORMANCE  RESULTS 

To  estimate  the  performance  of  MCA  and  IHAMA  under  a  variety  of  conditions,  a  program  was  devel¬ 
oped  to  generate  random  networks.  For  each  netwwk,  the  program  computed  its  connectivity,  computed  a 
backbone,  performed  transmitter  (IHAMA)  or  receiver  (MCA)  scheduling,  and  estimated  the  load  capacity 
of  the  network.  The  latter  was  averaged  across  many  generated  networks,  resulting  in  performance  curves. 

3.1  Random  Network  Generation 

In  our  simulator,  the  parameters  that  control  network  topology  are  the  number  of  nodes  in  the  network 
(network  size),  the  normalized  communication  range,  and  the  random  number  for  positioning  the  nodes. 
With  the  network  size  and  the  normalized  communication  range  defined,  a  network  is  generated  by  ran¬ 
domly  positioning  each  node  in  a  unit  square.  After  all  nodes  are  positioned,  a  connectivity  table  is  com¬ 
puted  by  determining  whether  the  distance  between  node  pairs  is  less  than  the  normalized  communication 
range. 

The  simulations  examined  network  sizes  from  12  to  50  nodes  and  normalized  communication  ranges 
from  0.25  to  1.4  (multihop  to  fully  connected).  The  performance  of  each  network  was  examined  using  the 
techniques  described  in  Sections  2.2  and  2.4.3.  For  each  combination  of  network  size  and  normalized  com¬ 
munication  range,  the  load  capacities  of  KXX)  randomly  generated  networks  were  computed  and  averaged 
together.  The  following  sections  present  some  of  these  performance  results.  For  clarity  only  the  average 
performance  is  shown,  however,  the  variance  was  found  to  be  relatively  small. 

Due  to  the  desire  to  keep  the  results  general  and  independent  of  equipment  performance  issues,  neither 
MCA  nor  IHAMA  results  include  any  estimate  of  overhead.  Overhead  was  not  addressed  because  it 
depends  on  implementation  details,  which  are  beyond  the  scope  of  this  report.  The  overhead  of  IHAMA 
and  MCA  are  thought  to  be  compTtarable. 

3.2  Load  Capacity 

Figures  4  and  5  show  the  Normalized  Load  Capacities  of  the  different  MCA  configurations  and  single¬ 
channel  Idealized  HAMA  (IH  AM  A/SC)  for  12-node  and  50-node  networks,  respectively.  The  abscissa  can 
be  divided  into  three  distinct  regions  depending  on  the  value  of  the  Normalized  Communication  Range  p' : 
multihop  networks  (p'  <  0.65),  star  networks  (0.65  <  p'  <  1.2),  and  fully  connected  networks  ( 1.2  <  p'). 

Many  of  the  features  exhibited  in  Figs.  4  and  5  are  readily  recognized  given  the  performance  equations 
for  IHAMA  (see  Section  2.2)  and  MCA  (see  Section  2.4.3).  For  example,  as  noted  in  Section  2.4.3,  the 
Normalized  Load  Capacity  of  a  fully  connected  MCA  network  is  given  by  =  n^.  This  accounts  for 
the  shapes  of  the  curves  for  MCA  networks  shown  in  Figs.  4  and  5  over  the  range  1.2  <  p' .  Actually,  the 
results  show  that  the  range  over  which  extends  to  1.0 <p'.  This  is  because  the  range 

1.0  <  p'  <  1.2  corresponds  to  star  networks  with  ^  and  we  know  that  under  these  condi¬ 

tions.  These  relationships  result  in  the  steeper  curves  for  the  50  node  networks  as  compared  to  12  node  net¬ 
works,  since  there  is  a  higher  probability  of  a  large  number  of  fully  connected  nodes  in  a  larger  network. 

When  p'  becomes  increasingly  smaller  than  1.0,  the  number  of  fully  connected  nodes  in  the  star  net¬ 
works  approaches  1.  As  this  occurs,  decreases  from  its  maximum  value  and  asymptotically 
approaches  its  multihop  value  (p'  <0.65).  For  =  5.  this  asymptotic  value  is  approximately  1.0.  This 
implies  that,  for  nearly  all  networks  generated,  five  receivers  per  node  was  enough  to  guarantee  that  each 
relay  node  could  always  continuously  monitor  the  transmissions  of  its  neighboring  relay  nodes. 
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Nonnalized  Communication  Range 

Hg.  4  —  Compaiison  of  the  normalized  load  capacities  of  12-Dode  IHAMA  and  MCA  networks 


For  IHAMA  networks,  die  normalized  load  capacity  begins  to  decrease  as  soon  as  full  connectivity  is 
lost  (i.e.,  when  p'  is  just  below  the  value  1.2).  As  the  Normalized  Communication  Range  cteCTeases  below 
1.2,  full  connectivity  is  lost  and  star  networks  are  {xoduced.  In  IHAMA,  the  Normalized  Load  Cqiacity  is 
given  by  =  1/  (2  -  k/N) .  When  the  Normalized  Communication  Range  is  reduced  so  diat  there 
are  few  networks  generated  diat  have  any  fully  connected  nodes,  multihop  networks  dominate  the  results. 
Recall  that  in  the  multihop  IHAMA  networks,  the  normalized  load  capacity  varies  apjnxiximately  as 
1/(B+1). 

In  MCA,  the  performance  of  the  network  is  only  dependent  on  the  performance  of  die  worst  case  relay 
connectivity.  (The  results  of  the  MCA  performance  have  not  been  solved  in  closed  form,  but  were  gener¬ 
ated  by  a  queuing  simulation.)  However,  it  is  apparent  from  the  results  shown  in  Figs.  4  and  5  that  diere  is 
litde  or  no  dependence  of  the  normalized  load  capacity  on  tlK  number  of  relays  required  in  the  multihop 
regime.  On  the  other  hand,  IHAMA  performance  continues  to  detericM-ate  as  the  network  becomes  sparser. 

The  most  interesting  feature  in  Figs.  4  and  S  is  the  multihop  performance  of  MCA,  whidi  corresponds 
to  Normalized  Communication  Ranges  less  than  approximately  0.65.  As  the  number  of  receivers  increases, 
die  N(»inalized  Load  Ctqiacity  of  multihop  netwOTks  rtqiidly  approaches  1.0.  This  has  profound  implica¬ 
tions  for  the  operation  of  die  networks.  A  Normalized  Load  Capacity  of  1.0  indicates  that  all  of  the  trans¬ 
mitters  on  the  backbone  are  on  all  of  the  time  and  there  are  enough  receivers  to  listen  to  every 
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Normalized  Communication  Range 

Fig.  S  —  Compaiison  of  the  normalized  load  capacities  of  SO-node  IHAM  A  and  MCA  networks 


transmission.  It  also  permits  traffic  to  be  streamed  through  the  network,  resulting  in  very  low  end-to-end 
delays.  These  low  delays  introduce  the  possibility  of  an  integrated  voice-data  network. 

3.3  Equipment  Normalized  Results 

Since  MCA  is  generalized  for  an  arbitrary  number  of  receivers,  we  need  a  technique  for  comparing 
systems  with  differing  equipment  requirements.  One  of  the  most  obvious  methods  of  doing  this  is  by  nor¬ 
malizing  the  performance  by  the  total  cost  of  the  system.  Owing  to  the  variable  costs  of  hardware,  we  use 
a  simpler  normalization  technique.  We  define  the  Equipment  Normalized  Load  Capacity  L"  as  the 
Normalized  Load  Capacity  divided  by  the  number  of  strings  of  equipment  (transmitters  and  receivers). 
This  assumes  that  the  cost  of  a  receive  string  is  approximately  the  same  as  the  cost  of  a  transmit  string. 
Thus,  if  each  node  has  one  transmit  and  one  receive  string,  the  Normalized  Load  Ct^acity  is  divided  by  2 
to  obtain  the  Equipment-Normalized  Load  Capacity. 

Figures  6  and  7  show  the  Equipment-Normalized  Load  C^>acity  of  five  different  MCA  configurations 
and  a  one-transmitter,  one-receiver.  Idealized  HAMA  configuration  for  12-node  and  50-node  networks. 
The  MCA  performance  curves  all  use  one  transmitter,  but  the  number  of  receivers  ranges  from  one  to  five 
as  indicated  on  the  legend.  These  figures  are  obtained  from  Figs.  4  and  5  by  dividing  the  MCA  results  by 
n^+\  and  dividing  the  IHAMA results  by  2. 
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It  is  clear  from  Figs.  6  and  7  that  for  both  network  sizes  all  of  the  MCA  conhgurations  outperform 
IHAMA,  independent  of  the  Normalized  Communication  Range.  What  is  especially  striking  is  the  fact  that 
simply  allowing  the  use  of  multiple  frequencies  results  in  improved  performance  with  MCA  versus 
IHAMA  even  in  the  one-transmitter,  one-receiver  case. 

An  interesting  aspect  of  the  MCA  multihop  performance  is  the  fact  that  networks  with  more  receivers 
do  not  necessarily  produce  higher  ENLCs.  For  example,  for  50  node  networks,  one  transmitter  and  three 
receivers  appears  to  maximize  the  ENLC,  while  one  transmitter  and  two  receivers  optimizes  the  same 
quantity  for  12  nodes.  Of  course,  this  is  because  in  very  sparse  networks,  it  is  inefficient  to  have  more 
receivers  at  a  node  than  there  are  neighboring  transmitting  nodes. 

The  ENLC  ratio  is  defined  as  the  ENLC  of  MCA  divided  by  the  ENLC  obtained  with  IHAMA.  This 
ratio  gives  a  clearer  picture  of  the  cost  benefits  of  one  configuration  over  another.  These  ratios  are  given  for 
12-node  networks  in  Fig.  8  and  for  50  node  networks  in  Rg.  9.  MCA  ENLC  gains  over  IHAMA  of  as 
much  as  hve-to-one  are  achievable,  with  gains  of  two-to-one  common.  It  is  also  noted  that  these  perfor¬ 
mance  gains  are  significantly  higher  for  50  node  networks  than  for  12  node  networks. 

3.4  Related  Issues 

We  have  addressed  only  the  issue  of  load  capacity  and  ENLC  for  comparing  the  MCA  and  IHAMA 
architectures.  However,  fiiese  performance  results  and  the  structure  of  the  systems  give  insight  into  other 
important  issues  such  as  han^ng  voice  traffic,  frequency  usage,  end-to-end  delays,  operational  security. 
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Fig.  7  —  CompatisoD  of  IHAMA  and  MCA  on  a  perfonnance-per-equipment  basis  for  a  SO-node  netwoik 


and  robustness  to  jamming.  In  this  section,  these  issues  are  examined  by  considering  some  of  the  theoreti¬ 
cal  limitations  of  HAMA  and  MCA.  We  also  examine  some  of  the  issues  that  relate  to  the  implementation 
of  MCA  and  IHAMA  systems. 

3.4.1  Virtual  Circuits  and  Voice 

TWo  related  classes  of  service  that  are  important  for  Navy  intratask  force  communications  are  virtual 
circuit  connections  and  voice  service.  A  virtual  circuit  connection  can  be  defined  as  a  virtual  path  provid¬ 
ing  low  delay  and  a  specified  bandwidth  of  data  between  a  source  and  any  number  of  destinations.  Due  to 
the  high-ttiroughput,  low-delay  requirements  of  voice,  voice  service  requires  the  use  of  a  virtual  circuit  for 
implementation. 

The  implementation  of  a  virtual  circuit  in  IHAMA  is  limited  by  several  factors.  If  a  single  IHAMA 
system  is  used  and  relaying  is  necessary,  the  receivers  must  synchronize  with  the  transmitter  on  every  slot. 
This  requirement  means  that  the  minimum  delay  for  each  relay  node  is  one  slot  In  addition,  since  the  nor¬ 
malized  load  capacity  of  an  IHAMA  system  with  only  one  (nonrelay)  node  sourcing  traffic  is  1/  (B+\) , 
each  relay  gets  only  every  {B+\)th  slot.  This  results  in  a  minimum  delay  of  (£  -(- 1 )  slots  if  the  assign¬ 
ments  are  set  up  in  the  “proper”  order.  For  HF  systems,  the  slot  size  is  typically  more  than  0.5  s  for  effi¬ 
ciency  reasons.  This  limits  voice  circuits  to  two-hop  links  (fw  a  1.0  s  delay).  Alternatively,  if  a  multi¬ 
frequency  IHAMA  system  could  be  constructed  that  used  only  a  single  backbone  network,  then  with 
(B  + 1 )  IHAMA  systems,  the  traffic  source  and  each  relay  transmitter  could  be  on  all  of  the  time,  and 
voice  traffic  could  be  streamed  through  the  system  with  very  low  delay. 
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Hg.  8  —  Equipment  Nonnalized  Perfonnance  Ratio  Curves  for  a  12-Dode  netwoiic 


MCA  has  a  much  more  effective  technique  for  creating  and  maintaining  virtual  connections.  Since 
each  node  in  the  backbone  network  has  a  unique  frequency,  all  of  them  can  transmit  simultaneously.  To  set 
up  a  virtual  circuit,  all  that  is  required  is  that  each  relay  n^  have  a  receiver  tuned  “upstream”  to  listen  to 
the  transmissions.  This  virtual  connection  is  set  up  using  a  sinq>le  control  message  sequence  that  directs 
each  relay  node  to  tune  one  of  its  receivers  upstream.  If  a  bidirectional  link  is  desired,  nodes  must  be 
equipped  with  two  receivers;  one  looking  upstream,  the  other  downstream.  Due  to  the  fact  that  the  trans¬ 
mitters  and  receivers  are  constantly  active  when  implementing  a  virtual  channel,  the  delay  rates  can  be  as 
low  as  tens  of  milliseconds  per  hop. 


3.4.2  Delays 

To  adequately  compare  IHAMA  and  MCA  systems,  we  should  consider  both  the  load  capacity  and 
delay  of  these  systems.  We  have  examined  the  load  capacities  of  both  IHAMA  and  MCA  in  detail.  Delay 
cannot  be  characterized  with  the  analyses  and  simulations  we  performed.  However,  under  limited  condi¬ 
tions,  the  average  delays  at  each  relay  node  can  be  approximate.  These  node-by-node  t^proximations  do 
not  tell  the  whole  story,  but  they  do  give  insight  into  the  relative  magnitudes  of  delays  between  MCA  and 
IHAMA. 

The  delays  of  a  three-transmitter,  three-receiver  MAMA  system  are  compared  with  that  of  a  one- 
transmitter,  five-receiver  MCA  system  in  the  absence  of  queuing.  We  fiirther  idealize  the  multichannel 
MAMA  system  by  assuming  that  connectivities  are  the  same  for  each  MAMA  channel.  This  permits  the 
MAMA  system  to  easily  identify  a  single-backbone  network  for  relaying.  The  delays  that  we  diall  com¬ 
pute  for  the  single-backbone,  multichannel  MAMA  system  are  less  than  those  obtained  if  each  IHAMA 
channel  had  its  own  backbone  network.  Our  comparison  is  “fair”  in  that  both  the  MCA  and  MAMA  sys¬ 
tems  require  the  same  number  of  equipment  suites. 
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Rg.  9  —  Equipment  Noimalized  Performance  Ratio  Curves  for  a  SO-node  network 


For  fully  connected  networks,  both  example  IHAMA  and  MCA  systems  experience  a  delay  (i.e.,  the 
time  the  first  bit  is  transmitted  until  the  last  bit  is  received)  of  one  packet  transmission  duration  T p,  since 
all  nodes  receive  the  traffic  immediately. 

If  the  network  is  a  star  network,  the  traffic  transmitted  by  each  relay  node  is 
{N-k)  (l/k)  +l  =  Nf/k,  and  the  traffic  transmitted  by  each  nonrelay  node  is /.Therefore,  for  the  exam¬ 
ple  multihrequency  IHAMA  network,  the  fraction  of  the  total  capacity  of  3C  that  is  used  by  the  relay  nodes 
is  3  C/  ( 2  -  k/N)  >  C.  Thus,  for  any  time  slot,  a  transmitter  will  be  free  and  a  minimum  delay  of  2  Tp  will 
be  experienced  by  relayed  traffic,  one  for  the  original  transmission  and  one  for  the  relay^.  For  the  example 
MCA  network,  the  relays  are  constantly  active,  resulting  in  the  same  delay. 

Multihop  network  topologies  for  the  example  MCA  system  experience  a  minimum  delay  of  Tp  per 
relay  node  traversed  since  each  relay  constantly  transmits.  Hiis  results  in  an  end-to-end  delay  equal  to  the 
maximum  network  diameter  (in  number  of  hops)  times  7^.  In  the  example  muldfiequency  IHAMA  sys¬ 
tem,  each  relay  only  transmits  3/  (R  + 1  -  B/N)  of  the  time.  If  B  is  greater  than  2,  each  relay  will  add  a 
delay  averaging  more  than  Tp.  Thus,  the  example  MCA  system  has  the  same  or  lower  delay  than  the 
equivalently  equif^d  example  multifrequency  IHAMA  system  for  any  network  topology. 


4.  We  assume  that  a  node  does  not  begin  to  relay  a  packet  until  the  packet  has  been  received  in  its  entirety. 
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3.4.3  Frequency  Usage 

It  might  be  argued  that  the  performance  gains  of  the  MCA  over  IHAMA  are  a  result  of  the  fact  that  the 
MCA  uses  many  frequencies  (ideally  one  frequency  per  node).  To  see  that  this  is  not  the  case,  we  consider 
the  theoretical  limits  to  MCA  performance  that  result  from  limiting  the  number  of  frequencies  available  to 
MCA.  A  minimum  frequency  requirement  can  be  derived  and  can  be  compared  to  the  required  number  of 
IHAMA  systems  needed  to  perform  at  the  same  throughput. 

In  an  MCA  system  with  B  relay  nodes,  the  greatest  number  of  frequencies  that  must  be  active  at  any 
time  to  support  unidirectional  virtual  circuits  is  B  +  1 .  Each  relay  node  can  transmit  at  any  time  and  only 
one  nonrelay  node  can  enter  traffic  into  the  backbone  network  at  a  time^.  Thus,  an  MCA  system  can  be 
limited  to  B  +  1  frequencies  with  no  degradation.  If  we  assume  an  MCA  system  with  one  transmitter  and 
five  receivers,  the  normalized  load  capacity  of  all  multihop  networks  is  almost  exactly  1 .0.  To  get  the  same 
or  better  performance  from  an  IHAMA  system,  B  +  1  transceiver  pairs  and  B  +  1  frequencies  would  have 
to  be  used.  Thus,  a  one-transmitter,  five-receiver  MCA  system  has  the  potential  to  use  frequencies  as  effi¬ 
ciently  as  IHAMA. 

To  compare  MCA  and  IHAMA  performance  for  the  case  where  there  are  not  enough  frequencies  to 
permit  relay  nodes  to  have  separate  frequencies,  we  make  the  same  assumption  that  we  made  for  the  multi¬ 
frequency  IHAMA  system.  Namely,  we  idealize  the  system  by  assuming  that  connectivities  are  the  same 
for  each  frequency  channel.  This  enables  the  MCA  system  to  easily  identity  a  single-backbone  network  for 
relaying. 

If  the  number  of  frequencies  available  to  a  five-receiver  MCA  system  isjHmited  to  a  fixed  number  F,  a 
transmission  schedule  can  be  constructed  for  multihop  networks  that  gives  a  normalized  load  capacity  of 
F/  {B+\)  for  the  case  F <  B;  otherwise,  the  normalized  load  capacity  is  almost  exactly  1.0  for  the  case 
F>B.  Figure  10  shows  how  the  transmissions  are  scheduled  to  achieve  this  performance.  If  the  number  of 
frequencies  is  reduced  to  1 ,  a  normalized  load  capacity  and  schedule  identical  to  that  for  a  single-channel 
IHAMA  will  result!  This  indicates  that,  in  terms  of  theoretical  limits  on  the  load  capacity,  IHAMA  is  a 
degenerate  case  of  the  MCA  for  one  receiver,  one  transmitter,  and  one  frequency. 


3.4.4  Operational  Security  and  Robustness  to  Jamming 

Another  comparison  to  be  made  between  MCA  and  IHAMA  is  their  resistance  to  jamming  and  traffic 
analysis.  Using  IHAMA,  only  one  transmitter  is  on  at  any  time  and  only  one  frequency  is  used.  An  inter¬ 
ceptor  of  this  signal  can  infer  by  the  amount  of  time  that  a  node  is  on  whether  the  node  is  an  ordinary  node 
or  a  relay  and  how  much  traffic  each  ordinary  node  enters  into  the  network.  The  opponent  can  then  plan  a 
jamming  response  to  disconnect  the  network  by  jamming  a  critical  relay  at  the  right  time.  The  jammer  can 
thus  optimize  the  use  of  power  in  two  ways:  by  restricting  the  frequency  that  the  jammer  is  used  on  and 
restricting  the  jamming  time. 

The  MCA  allows  every  node  to  transmit  all  of  the  time  on  its  unique  frequency.  If  the  node  has  noth¬ 
ing  to  transmit,  a  dummy  message  can  be  sent.  Since  the  messages  are  likely  to  be  encrypted,  the  intercep¬ 
tor  cannot  detect  the  difference  between  a  dummy  message  and  real  traffic.  Therefore,  with  all  of  the  nodes 
transmitting  at  all  times  on  different  frequencies,  the  interceptor  can  gain  no  knowledge  of  the  network 
traffic  pattern  or  structure.  Without  this  knowledge,  the  only  januning  technique  the  interceptor  can  be  sure 


5.  This  assumes  that  a  virtual  circuit  consumes  nearly  all  of  the  transmission  edacity  of  a  relay  node.  In  practice,  this 
may  not  be  the  case,  which  leads  to  the  possibility  of  multiple  virtual  circuits  and/or  voice/data  integration. 
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Fig.  10  —  Methodology  for  ftequency  assignment  a)  Three-bop  network  with  relay  nodes  in  black,  b) 
Transmission  frequency  schedule  assignment  with  three  frequencies.  (Source  schedule  is  distributed 
evenly  to  all  nonrelays.)  c)  Schedule  assignment  with  two  frequencies.  (Source  schedule  is  distributed 
evenly  to  all  nonrelays.) 


will  disrupt  the  network  is  to  jam  all  frequencies  all  of  the  time  with  sufficiently  high  power,  a  task  that  is 
generally  not  possible. 

3.4.5  Implementation  Issues 

This  report  has  focused  on  the  performance  of  two  idealized  systems,  MCA  and  IHAMA.  Can  real 
implementations  approach  the  performance  of  these  idealized  systems?  In  the  next  few  sections,  we  exam¬ 
ine  some  of  the  technical  problems  that  arise  in  implementing  such  systems. 

3.4.5.1  Frequency  Requirements 

An  idealized  MCA  network  can  work  with  as  few  as  one  frequency;  however,  the  preferred  mode  of 
operation  is  to  assign  a  unique  transmit  frequency  to  each  node.  If  there  are  not  enough  ^quencies  to  per¬ 
mit  the  latter,  then  additional  protocols  must  be  developed  to  coordinate  frequency  usage.  Frequencies 
might  be  allocated  deterministically  (statically)  or  nondetermini^cally  (dynamically).  For  networks  where 
a  significant  portion  of  the  traffic  is  broadcast,  which  is  the  case  that  we  have  been  considering,  the  goal  of 
the  MCA  is  to  allow  uninterrupted  transmissions  by  relay  nodes  on  the  backbone.  It  ^)pears  that  any 
scheme  for  dynamically  allocating  frequencies  among  all  the  nodes  of  a  network  is  only  going  to  be  as  reli- 
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able  as  the  communications  that  is  required  to  support  these  schemes.  In  times  of  stress,  intratask  force 
communication  links  may  be  highly  unreliable;  hence,  dynamic  frequency  allocation  schemes  do  not  seem 
to  be  appropriate.  Purely  static  allocation  schemes  have  the  drawback  that  transmission  capacity  alloca¬ 
tions  might  not  accurately  reflect  actual  needs.  A  hybrid  approach  in  which  a  subset  of  nodes  are  allocated 
their  own  frequencies  and  the  remaining  nodes  use  slot-handoff  protocols  to  share  the  remaining  frequen¬ 
cies  seems  to  be  a  promising  compromise.  This  would  be,  in  effect,  an  integrated  MCA/IHAMA  system. 

3.4.5.2  Multiple  Receivers 

Our  results  show  that  near-optimum  performance  can  be  obtained  for  multihop  MCA  networks  with 
five  receivers.  Additional  protocols  must  be  developed  to  achieve  the  results  shown  for  fewer  receivers.  It 
should  not  be  difficult  to  implement  efficient  protocols  for  doing  receiver  scheduling  since  nodes  only  need 
to  coordinate  with  their  neighbors  to  effect  the  required  coordination. 

3.4.5.3  Global  Knowledge 

Unlike  MCA,  whose  performance  is  only  weakly  dependent  on  the  number  of  relay  nodes,  IHAMA 
performance  degrades  rapidly  with  the  increasing  number  of  relays  required.  Thus,  IHAMA  needs  global 
connectivity  information  so  as  to  minimize  the  number  of  relays  needed.  IHAMA  also  needs  global  knowl¬ 
edge  about  the  traffic  loads  so  that  it  can  handoff  transmission  slot  opportunities.  The  implementation  of 
slot  handoff  among  nodes  that  are  not  directly  connected  is  a  significant  technical  problem. 


4.  CONCLUSIONS 

We  have  described  the  MCA,  a  mobile  radio  architecture  for  Navy  intratask  force  networks  that  is  gen- 
eralizable  to  arbitrary  numbers  of  transmitters,  receivers,  and  frequencies.  This  architecture  is  formed  by  a 
robust  reorganization  procedure,  the  Linked  Cluster  Algorithm.  In  comparison  with  an  idealized  form  of 
HAMA,  a  single-channel  architecture,  it  was  found  that  the  load  capacity  ol'MCA  was  superior  for  equiv¬ 
alent  cost  systems.  MCA  also  outperformed  IHAMA  in  other  performance  issues  such  as  delay,  the  ability 
to  handle  voice  and  virtual  circuits,  and  jam  resistance.  Finally,  it  was  shown  that  the  IHAMA  is  a  degen¬ 
erate  case  of  the  MCA  for  one  transmitter,  one  receiver,  and  one  frequency. 

Given  the  results  presented  in  this  report,  it  appears  that  the  MCA  should  be  considered  strongly  as  a 
candidate  for  use  in  future  Naval  intratask  force  networking  for  the  following  reasons; 

•  Multichannel  MCA,  using  the  same  one-transmitter/one-receiver  configuration  as  a  single-channel 
IHAMA  system  can  provide  better  performance. 

•  The  capacity  growth  with  MCA  can  be  effected  by  adding  receivers,  a  cost-effective  growth  path 
to  higher  capacity. 

•  MCA  hardware  can  be  updated  one  node  at  a  time  and  maintain  operability  throughout  the 
upgrade. 

•  It  takes  advantage  in  hardware,  with  its  one-transmitter/multiple-receiver  configuration,  of  the  faa 
that,  in  a  Fleet  intratask  force  system,  ships  and  aircraft  will  listen  more  than  transmit. 

•  The  insensitivity  of  MCA  throughput  performance  to  the  sparseness  of  networks  opens  up  the  10 
to  30  MHz  HF  and  UHF  bands  for  Naval  intratask  force  networking. 


The  MCA  can  handle  voice. 
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•  The  high  throughput  and  low  delay  makes  integrated  voice-data  networking  feasible. 

•  MCA  can  be  combined  with  slot  handoff  schemes  when  the  number  of  frequencies  available  does 
not  permit  the  allocation  of  a  unique  frequency  to  each  MCA  node. 

Perhaps  the  most  powerful  featme  of  the  MCA  is  the  potential  to  support  virtual  circuits  for  point-to- 
point  traffic  and  broadcasting  from  one  node  to  all  others.  This  feature  is  needed  for  time-critical  services 
such  as  voice.  It  may  also  prove  to  be  the  preferred  method  to  send  NTDS  and  some  of  the  other  data  traf¬ 
fic. 
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APPENDIX 


Approximating  ttie  Minimum  Backbone  Network 


As  indicated  in  Section  2.2,  the  load  capacity  of  an  IHAMA  network  is  heavily  dependent  on  the  num¬ 
ber  of  relay  nodes  B.  By  minimizing  the  number  of  required  relay  nodes  used  for  a  network,  the  perfor¬ 
mance  of  IHAMA  can  be  optimized.  Any  valid  set  of  relays  must  fulfill  two  criteria:  every  node  in  the 
network  must  be  connected  to  at  least  one  relay  and  the  relays  must  form  a  connected  subnet.  A  valid  set  of 
relays  with  the  minimum  number  of  relays  is  termed  a  Minimum  Backbone  Network  (MBN). 

USING  GLOBAL  KNOWLEDGE 

The  MBN  can  be  determined  using  global  knowledge  of  the  network  connectivity.  Unfortunately,  the 
exact  solution  of  the  MBN  for  large  networks  is  computationally  infeasible.  However,  for  comparing  the 
MCA  and  IHAMA  architectures,  it  is  not  necessary  to  compute  the  MBN  but  rather  to  compute  a  common 
backbone  network  (BN)  that  is  used  by  both  architectures.  When  global  connectivity  information  is 
known,  the  network  can  be  represented  as  an  undirected  graph.  The  vertices  and  edges  of  the  graph  repre¬ 
sent  the  nodes  and  bidirectional  links  of  the  network,  respectively. 

Figure  A1  gives  a  heuristic  for  approximating  the  MBN  of  an  undirected  graph.  In  line  1,  the  set  of 
clusterhead  nodes  is  determined  as  follows.  Each  node  has  three  attributes  called  nodejd,  own_head,  and 
label.  Tbe  nodes  are  first  numbered  (nodejd  is  set)  from  1  to  N;  own.head  is  initialized  to  0;  and  label  is 
set  to  UNLABELED.  Then  node  1  is  labeled  a  CLUSTERHEAD  and  its  own_head  is  set  to  1 .  Ail  nodes 
connected  to  the  new  clusterhead  are  temporarily  labeled  as  1N_A_(XUSTER,  and  their  own_head  is  also 
set  to  1 .  The  lowest  numbered  node  that  is  not  labeled  CLUSTERHEAD  or  IN_A_CLUSTER  becomes  the 
next  CLUSTERHEAD.  The  new  clusterhead  sets  own_head  to  its  own  nodejd.  UNLABELED  nodes  con¬ 
nected  to  flie  new  clusterhead  are  labeled  as  IN_A_CLUSTER,  and  the  own_head  of  each  is  also  set  to  the 
nodejd  of  the  new  clusterhead.  The  process  is  repesUed  until  all  nodes  are  labeled  as  either  CLUSTER- 
HEAD  or  IN_A_CLUSTER. 

In  line  2,  nodes  that  were  temporarily  labeled  as  IN_A_CLUSTER  are  relabeled  as  BOUNDARY_ 
NODE  if  a)  the  node  has  a  neighbor  with  a  different  own_head  than  the  node’s  own.head  and  b)  the  neigh¬ 
bor’s  own_head  is  not  connected  to  the  node’s  own_head.  In  line  3,  all  nodes  still  labeled  IN_A_CLUS- 
TER  are  relabeled  TERMINATOR_NODE. 

After  initializing  the  BN  to  the  empty  set  in  line  4,  lines  S  through  8  implement  a  greedy  algorithm  in 
which  the  non-TERMINATOR_NODEs  that  will  add  the  most  new  neighbors  to  the  BN  are  chosen  as  new 
members  of  the  BN.  This  is  done  until  the  BN  is  connected  to  every  node  in  the  network.  The  next  and 
most  computationally  intensive  task  (lines  9  through  17)  is  to  make  sure  that  the  BN  is  a  connected  subnet¬ 
work.  This  is  accomplished  by  doing  a  shortest-path  comiHitation  (Dijkstra’s  Algorithm)  from  every  node 
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1  find  set  of  clusterhead  nodes 

2  label  nodes  connecting  CLUSTERHEADs  BOUNDARY_NODE 

3  all  other  non  CLUSTERHEAD  nodes  labeled  TERMlNATOR_NODE 

4  initialize  BN  to  the  empty  set 

5  while  BN  is  not  connected  to  all  nodes 

6  find  non  TERMlNATOR_NODE  that  adds 

7  maximal  neighbors  to  BN 

8  add  node  to  BN 

9  weight  each  link  (i,j)  as  follows: 

10  case  {i,j)  unconnected  label  Infinity 

11  case  i  or  j  is  TERMtnaT0R_N0DE  label  Infinity 

12  case  i  and  j  on  BN  label  1 

13  case  i  on  BN  or  j  on  BN  label  10 

14  otherwise  label  100 

15  find  shortest  paths  across  network 

16  use  paths  generated  to  connect  BN 

17  add  nodes  used  to  connect  to  BN 

Fig.  A1  —  Algorithm  to  compute  a  backbone  network  using  global  knowledge 


chosen  as  part  of  the  BN.  Other  links  are  labeled  such  that  a  minimal  number  of  nodes  are  added  to  the  BN. 
Links  that  add  no  nodes  cost  1,  one  node  costs  10,  and  2  nodes  cost  100.  Finding  the  shortest  path  using 
these  link  costs  ensures  that  a  nearly  minimal  number  of  nodes  will  be  added  to  provide  connectivity  along 
the  BN.  The  added  nodes  are  discovered  in  line  17  and  added  to  the  BN. 

The  backbone  networks  generated  by  this  method  appear  to  be  sensitive  to  the  way  in  which  the  nodes 
are  numbered.  If  the  method  is  replicated  several  times  by  using  different  sets  of  random  numberings  of  the 
iKxles,  the  smallest  backbone  network  appears  to  be  very  close  to  the  MBNs  derived  by  careful  visual 
inspection.  Panel  (b)  of  Figs.  A3  through  A5  show  some  examples  of  networks  and  BNs  computed  using 
global  knowledge.  These  figures  illustrate  how  p'  relates  to  topology  and  compare  the  BNs  obtained  with 
global  and  local  knowledge.  As  can  be  seen  in  panel  (a)  of  Figs.  A3  through  A5,  the  local-knowledge  BN 
provides  a  larger  backbone  than  does  the  global-knowledge  algorithm.  This  is  unavoidable  because  of  the 
limitation  of  the  information  available. 

USING  LOCAL  KNOWLEDGE 

The  potentially  rapid  topology  change  in  an  intratask  force  network  may  necessitate  using  only  local 
information  for  structuring.  This  will  typically  result  in  developing  backbone  networks  that  are  far  from 
optimal.  However,  the  redundancy  in  the  backbone  can  be  used  to  advantage  to  provide  more  reliable  mes¬ 
sage  delivery.  This  section  describes  the  formation  of  a  backbone  network  by  using  a  distributed  algorithm 
and  local  topology  knowledge. 

In  the  distributed  formation  of  the  BN,  both  the  communication  sequence  and  the  algorithm  must  be 
illustrated.  In  the  algorithm  that  we  describe,  topology  information  need  only  be  relayed  once.  This  is 
known  as  two-hop  information,  since  the  traffic  comes  from  nodes  at  most  two  transmissions  (hops)  away. 

The  approach  that  was  taken  starts  with  breaking  the  network  up  into  clusters,  as  in  the  global-knowl¬ 
edge  case.  However,  the  information  and  structure  derived  from  clustering  is  used  more  extensively  by  the 
local-knowledge  algorithm.  With  only  two-hop  knowledge,  the  only  decision  that  a  cluster  can  make  about 
its  connections  to  neighbors  is  that  it  must  choose  BN  nodes  such  that  it  has  a  connection  to  all  clusters  that 
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have  nodes  within  two  hops.  This  is  actually  looking  three  hops  away,  but  the  effect  is  achieved  by  letting 
gateway  nodes  make  some  of  the  decisions. 

Due  to  the  integrated  behavior  of  the  conununications  and  computations,  we  list  the  processes  together 
in  Fig.  A2.  Note  that  all  communications  indicated  are  local  and  do  not  require  routing.  In  each  frame,  we 
require  that  nodes  transmit  in  sequence,  according  to  their  node  number. 


Frame  1 : 

Probe  to  learn  connectivity  information 
Frame  2 : 

Determine  clusterhead  status 

Complete  ack/nak  of  probes  and 

announce  connectivity  and  clusterhead  status 
End  of  Frame  2 : 

Compute  gateways 
Frame  3 : 

Report  clusterhead  connections 
End  of  Frame  3 : 

For  each  clusterhead 

Choose  min  set  of  nodes  to  connect  to  all 
adjacent  clusterheads 

Frame  4 : 

Clusterheads  report  BN  connections 

Boundary  nodes  report  2 -hop  clusterhead  connections 

Connect  to  unique  2 -hop  gateways 
Frame  5 ; 

Determine  2 -hop  gateway  connections 

Broadcast  2 -hop  gateway  connections 

Fig.  A2  —  Pseudocode  for  the  distributed  process  to  form  a  backbone  network  with  local  knowledge 

The  probe  transmissions  and  the  ACK/NAK  of  these  probes  in  frames  1  and  2  are  used  by  each  node  to 
discover  to  which  nodes  it  is  bidirectionally  connected  by  direct  links.  This  is  done  in  frame  1  by  sending  a 
message  at  each  node  with  a  bit  set  to  1  for  each  node  heard  previously  and  a  bit  set  to  0  for  those  nodes 
not  heard  from.  Since  each  node  can  only  have  heard  from  the  nodes  on  the  schedule  preceding  it,  the  i  th 
node  need  only  send  i  -1  bits.  However,  at  the  end  of  the  first  transmission,  the  full  bidirectional  connectiv¬ 
ity  has  not  been  established.  Thus,  the  transmission  in  frame  2  is  used  to  complete  the  ACK/NAK  with 
each  node  i  sending  the  remaining  N  -  i  bits  describing  the  connectivity.  In  addition,  in  frame  2  each  node 
sends  an  additional  bit,  which  is  called  the  “clusterhead  bit.”  This  is  used  to  indicate  whether  a  node  is  a 
clusterhead.  The  rule  for  setting  this  bit  is  simple:  if  no  neighbor  (i.e.,  node  to  which  a  bidirectional  link 
exists)  has  become  a  clusterhead,  set  the  clusterhead  bit,  label  the  node  as  a  clusterhead,  and  add  it  to  the 
BN. 

Once  the  clusterheads  are  announced  (at  the  end  of  frame  2),  the  gateway  nodes  can  be  computed  as 
those  connecting  two  clusterheads.  This  linkage  can  connect  either  overlapping  (i.e.,  gateway  is  connected 
to  both  clusterheads)  or  adjacent,  nonoverlaf^ing  (i.e.,  gateway  is  connected  to  one  of  the  clusterheads  and 
also  to  another  node  that  is  connected  to  the  second  clusterhead).  In  the  latter  case,  the  clusterheads  are 
linked  by  a  pair  of  gateways. 
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Tiransmissions  in  frame  3  are  used  by  all  nonclusterhead  nodes  to  report  the  clusterheads  to  which  they 
ate  attached.  With  this  information,  each  clusterhead  chooses  (at  the  end  of  frame  3)  a  minimal  set  of  gate¬ 
ways  that  are  connected  to  all  adjacent  clusterheads  and  labels  them  members  of  the  BN. 

During  transmissions  in  frame  4,  these  clusterhead  connections  to  BN  nodes,  along  with  a  list  of  all 
two-hop  clusterheads,  are  then  announced  by  each  clusterhead.  Once  this  information  is  passed  (at  the  end 
of  frame  4),  it  is  possible  to  form  the  two-hop  gateway  pairs.  A  node  becomes  one-half  of  a  two-hop  gate¬ 
way  pair  when  it  determines  that  the  addition  of  the  gateway  will  provide  connections  with  one  or  more 
clusters  not  already  two-hop  connected  to  any  neighboring  clusteiheads.  When  a  decision  is  made  to  form 
a  two-hop  gateway,  the  node  broadcasts  (in  frame  5)  the  connection(s)  it  has  made  by  using  a  list  of  bits. 
The  nodes  that  it  has  chosen  to  connect  to  also  become  two-hop  gateways  upon  receiving  this  transmis¬ 
sion.  At  the  end  of  transmissions  in  frame  5,  all  of  the  two-hop  gateways’  transmissions  will  have  been 
completed,  and  the  backbone  will  be  fully  formed.  It  is  guaranteed  that,  in  the  absence  of  errors,  the  BN 
will  provide  at  least  one  path  from  every  node  to  every  other  node  in  the  network. 

One  additional  step  can  be  added  to  decrease  the  size  of  the  BN.  Any  clusterhead  may  be  eliminated 
from  the  backbone  if  the  backbone  nodes  it  is  connected  to  form  a  connected  subgraph  that  is  connected  to 
all  other  nodes  in  the  cluster.  This  extra  step  requires  no  extra  communication  since  the  data  is  already 
present  at  the  clusterhead. 
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Rg.  A3  —  Example  backbone  for  a  20-Dode  network  with  p'  =0.3 
obtained  with:  a)  local  knowledge  and  b)  global  knowledge 
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(a)  Local  Knowledge 


(b)  Global  Knowledge 


Rg.  A4  —  Example  backbone  for  a  SO-node  network  with  p’  =  0.25 
obtained  with:  a)  local  knowledge  and  b)  global  knowledge 
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